OK, as I expected my previous entry sparked an active discussion - nothing like a good licences war to liven things up. But it was more civil than I expected. Here's a much more technical entry.
As I discovered, Test-Run-0.0115 consistently failed to pass "./Build test" on all BSD systems, while doing mostly fine on Linux. Inspecting the logs of the failure yielded a "File name too long" error. What happened was that I created a filename that was artificially very long (../t/../t/../t/), but still well within the limits of my Linux system's 4096 bytes limit for file paths. However, as I discovered the POSIX standard defined a minimum of 256 bytes for maximal paths which is what BSD is supporting.
The reason I had this long path in the first place was to make sure long paths are handled properly by the harness output after some customisations. This in turn was inspired by a problem I found when using Test-Run at my workplace for some internal test suite, which inspired me to write the Trim-displayed-Filenames plugin.
So after I received all these failure reports, I added some logic to t/output.t that makes use of POSIX::PATH_MAX() to keep the path at bay. A bit convulted, but it now passes on BSD systems (as well as Linux and Solaris), with a two isolated failures on Linux, which I have not looked into yet. I'd like to thank apeiron from Freenode for testing the pre-release in Mac OS X and verifying it works there.
In any case, I'm a bit tired of doing unknowledgable UNIX programming, and therefore would like to read the 2nd edition of Stevens' book (which is considered the Bible of UNIX programming). The book is kinda costy, and big (960 pages), so I think I'll renew my Safari subscription and see if I can read it there effectively. If I can't I'll just use it for something else, and order a paper-copy of the book.
And finally, I wonder how a 256-octets path limit can ever be enough. In this day and age of long filenames and UTF-8 ones (which require several bytes), one can expect that a path with a few especially long components will quickly overflow such a short limit. Can any BSD users comment?
Re:256 does sound rather short
ChrisDolan on 2008-04-19T04:39:41
1024 CYGWIN_NT-5.1 1.5.24(0.156/4/2) i686 [WinXP SP2]
1024 FreeBSD 6.2-STABLE i386
1024 Darwin 8.11.0 Power Macintosh [OSX 10.4.11]
1024 Darwin 8.11.1 i386 [OSX 10.4.11]
4096 Linux 2.4.32-grsec-opteron-peon-1.1.1 i686 [Debian ?]
4096 Linux 2.6.9-55.ELsmp i686 [RHEL4]
4096 Linux 2.6.18-53.1.14.el5PAE i686 [RHEL5]
4096 Linux 2.6.22-14-generic i686 [Ubuntu 7.10]
Interestingly, I saw the following in some cases, even on Linux:/usr/include/X11/Xwindows.h:#define PATH_MAX 1024
I found this article very interesting:
http://insanecoding.blogspot.com/2007/11/pathmax-simply-isnt.htmlRe:256 does sound rather short
Shlomi Fish on 2008-04-19T07:23:55
Thanks!
Interesting. I guess the original path I used was longer than 1024, but still shorter than 4096. 1024 does sound more reasonable. I guess the POSIX standard defines the minimal limit as "256" but some systems naturally have a greater value. I also know the Perl POSIX.pm contains "PATH_MAX", "_PC_PATH_MAX" and "_POSIX_PATH_MAX", but I'm not sure what the exact differences are.
Thanks for the link. It looks interesting, but since it's kinda long, I only skimmed it so far.
